%
% Copyright (C) Håkan Lindqvist 2006, 2007.
% May be copied freely for educational and personal use. Any other use
% needs my written consent (i.e. no commercial use without my approval).
%

% Access control

\label{chapter:access control}
\index{access control}

In the discussion about \texttt{secure states} in 
Section~\ref{protection states}, the core issue was
transfer of rights. What those rights really describe are the rights any
\texttt{principal} has to other \texttt{principals} in a
\texttt{system}. The transitions that were described take place as some
\texttt{subject} access some resource in some way. \texttt{Access
  control} is about regulating which resources that may be accessed and
how.

This chapter will begin by defining the two levels that exist for
\texttt{access control}. The distinction between them is very important
since the implications from their specification create two entirely
different models for how rights are controlled on a system.
After the theoretical foundation has been presented, a few real world
examples of the two models are presented, with the security implications
and problems that have arisen in those system.

%%%%%%%%%
\section{Definitions of access control specification levels}
\label{chapter:access control def}
The specification level of \texttt{access control} can be on either of
two levels: The specification is up to a \texttt{subject} or it
is handled by the operating system. The definition of each of these
models follow, adapted from~\cite{Bishop}.

\begin{definition}
\label{definition:DAC}
\index{definition!discretionary access control}
\index{discretionary access control}
If an individual \texttt{subject} can control the decision of an
\texttt{access control} mechanism so that it allows or denies access to an
\texttt{object}, that mechanism is a \texttt{discretionary access
control} (\texttt{DAC}), also called an \texttt{identity based access
control} (\texttt{IBAC}).
\end{definition}

\begin{definition}
\label{definition:MAC}
\index{definition!mandatory access control}
\index{mandatory access control}
When a system mechanism controls access to an \texttt{object} and an
individual \texttt{subject} cannot alter that access, the control is a
\texttt{mandatory access control} (\texttt{MAC}), occasionally called a
\texttt{rule-based access control}.
\end{definition}

It is important to note that the use of one of these does not prohibit
the use of the other. If both \texttt{MAC} and \texttt{DAC} are used,
both \texttt{access control} mechanisms must grant a \texttt{subject's}
right to access an \texttt{object}.


%%%%%%%%%
\section{Implications of different types of access control}
The implications of \texttt{MAC} and \texttt{DAC} \texttt{access
control} mechanisms are more far reaching than one might expect. The
most common by far in industry standard operating systems today is
\texttt{DAC} in various forms and expressiveness. All variations of
UNIX\footnote{UNIX is a registered trademark of The Open Group}
support it, as does Microsoft Windows\footnote{Windows is a registered
trademark of Microsoft Corporation}.

The main problem with \texttt{DAC} is that it has too many dependencies
for correctness. It depends on the correctness of the policy's
specification (cf. Chapter~\ref{chapter:policy}), the administrators
ability to assure that all \texttt{objects} on the system have rights as
specified and the correctness of all tools working with the
\texttt{objects}~\cite{inevitability}.

With \texttt{MAC} the main problem is the correct classification
of \texttt{subjects} and \texttt{objects} such that correct access
rights are enforced. Another issue is the comprehensibility of the
policy specification to the \texttt{MAC} 
mechanisms~\cite{usenix_dte_unix_prot, usenix_dte_root, flask}.


%%%%%%%%%
\section{Real world examples}
The real world is always more complex than what mere theoretical work
can express, many factors that pure theoretical settings do not need
to worry about must be handled. The provided example of the \texttt{MAC}
system is one such example, which is able to meet demands on the
enhanced security mechanisms to integrate seamlessly with the existing
binary software. 


%%%%%%%%%
\subsection{UNIX System V/MLS Access Control}
The Unix System V/MLS~\cite{Amoroso} combines both \texttt{DAC} and
\texttt{MAC} seamlessly. The discretionary part resides as is expected in
settings associated with the files on the system, while the mandatory
part of the \texttt{access control} resides as a part of the operating
system's kernel. The fact that the mechanism for \texttt{MAC} resides as
an isolated part of the kernel, and is used by system calls, minimizes
the intrusion of enforcement code in user space, which is an important
aspect.

It is important to note that the completeness of such an approach really
depends on the completeness of the hooks inserted into the system. That
is, that all parts of the system that change the system's state, with
respect to security, pass through the \texttt{MAC} enforcement
mechanism. Any relevant execution path that fails to do so will bring
the system into an insecure state.

%%%%%%%%%
\subsection{SunOS}
Almost all UNIX--like operating systems use \texttt{DAC} as their
primary \texttt{access control} mechanism. The SunOS\footnote{SunOS is
a trademark of Sun Microsystems, Inc} operating system is not an
exception. This ensures it, among most existing operating systems today,
a place among the implicitly insecure systems, as is argued 
in~\cite{inevitability}.

